Currently, when compiling a Go package with Assembly files, the go_library build rule invokes go tool asm once on all Assembly files in the package. However, this caused errors that look like the below when multiple files declare symbols with the same name.

asm: pkg/linux_amd64/github.com/apache/arrow-go/v18/internal/utils/min_max_sse4_amd64.s:8: symbol LCDATA1 redeclared
asm: pkg/linux_amd64/github.com/apache/arrow-go/v18/internal/utils/min_max_sse4_amd64.s:242: symbol LCDATA2 redeclared
asm: pkg/linux_amd64/github.com/apache/arrow-go/v18/internal/utils/min_max_sse4_amd64.s:460: symbol LCDATA3 redeclared
asm: pkg/linux_amd64/github.com/apache/arrow-go/v18/internal/utils/min_max_sse4_amd64.s:691: symbol LCDATA4 redeclared
asm: pkg/linux_amd64/github.com/apache/arrow-go/v18/internal/utils/min_max_sse4_amd64.s:847: symbol LCDATA5 redeclared
asm: assembly failed

This is despite the <> suffix after the offending symbol name, which should've been enough to make the symbol visible in that file only from the perspective of go tool asm.

When building this same package without Please (i.e. just with go build), we don't run into these errors - it looks like this is because the Go tool invokes go tool asm on each Assembly individually:

• https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/work/gccgo.go;l=212
• https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/work/gc.go;l=397

So this PR updates the go_library build def's behaviour to more closely match the behaviour in the Go tool.

I was able to reproduce these errors by adding the new unit tests in this PR. The errors were fixed by my updates to the go_library build def.